In some Central Processing Unit (“CPU”) system architectures, especially those used in battery-powered systems, power saving modes of the CPU are reflected via hardware mechanisms to the system core logic. Based on a well-defined set of bus semantics particular to the CPU, handshakes are achieved which allow core logic to then participate in deeper power saving modes. The deeper modes are most effective when they take advantage of known CPU latency characteristics. This is because system core logic power mode latency can be hidden behind known CPU latency. These latencies, as known in the art, include the time required to enter and/or exit a level of a power saving mode.
The Advanced Configuration and Power Interface (“ACPI”) Specification is an open standard for unified operating system-centric device configuration and power management. While the context of the present application is not limited to ACPI, it provides some definitions which are useful for understanding the power modes of industry standard CPU's. ACPI defines various CPU power states (“C-states”) of increasing power savings and, usually, with corresponding increasing latency in returning out of deeper level C-states. ACPI defines a mechanism for notifying Operating System (“OS”) software of the C-state capabilities and latencies of a CPU thread, core, and package based on CPU identity mechanisms that are known in the art. For example, a system may take approximately 15 microseconds to exit C2 and enter C0.
FIG. 1 is an exemplary state transition diagram for a CPU package and system which implements ACPI power states C0, C1, and C2, from the point of view of an OS that is using the software-abstracted mechanism for entering power saving modes. The power state transition diagram shows the logical (but not physical or bus-semantics) flow of CPU states in a typical computer system. The software-abstracted mechanism for entering power saving modes is the Monitor or “MWait” facility, which is provided by the CPU both to abstract the power saving hardware mechanisms and to extend and improve the facility to work well with multiple CPU cores within a package.
In FIG. 1 we see that a CPU in its normal execution state C0 can enter C1 through execution of a software instruction MWait. The MWait instruction is executed with “hint codes” that tell the CPU which preferred C-state it is to enter. The hardware then translates this into the appropriate semantics for the power saving mode. For the case of C1, there is no difference in front side bus semantics for C1 compared to C0, therefore the system core logic cannot differentiate a CPU in C1 compared to a CPU in C0.
The CPU can also enter C1 through the execution of a Halt (“HLT”) instruction. The HLT instruction stops all instruction flow in the CPU until a break event, such as a Non-Maskable Interrupt (“NMI”), System Management Interrupt (“SMI”), or other interrupt, which is asserted by external agents or the local interrupt hardware (LAPIC).
The MWait implementation improves upon the HLT instruction by virtue of a Monitor hardware facility. This is done to enable more threads and cores within a single package to participate in low power modes that require package coordination, such as those that will affect system Core logic power state, or CPU global package voltage, for example.
OS software can “arm” core or thread monitor hardware through sets of instructions that tell the core bus interface to look for a range of physical addresses on the bus. This facility allows other cores or threads within a package to “wake up” the otherwise halted core or thread by performing a write to the Monitor address. Thus, a software scheduler in an OS can use a fast, lightweight mechanism that does not involve the latency of an interrupt to break a core or thread from C1. If the core had been in Auto Halt, the only mechanism to wake it is an interrupt (“IPI”).
Similarly, a core or thread that supports C2/MWait will enter C2 when executing an MWait with the hint code appropriate for C2. Unlike for C1, when all the cores and threads have executed their MWait/C2, the CPU package hardware then makes the appropriate bus semantics for entering C2. These semantics notify the system core logic via an I/O transaction on the front side bus targeted to a particular address in system core logic hardware.
As with C2/MWait, deeper C-states such as C3/MWait and C4/MWait have their own bus semantics which complete with different sideband handshakes but that start with the same I/O transaction type, to diverse addresses in system core logic. OS software chooses amongst these lower power and higher latency states based on its own heuristics that are known in the art.
In the bus semantics of an exemplary CPU, when the I/O transaction, known as a Level-n (n=2,3,4) read, is completed, core logic issues Stop Clock (“STPCLK”) on the bus and the CPU acknowledges the STPCLK with a special address-only bus cycle. For higher level (n=3,4) C-n states, further semantics control CPU voltage modulation and front side bus quiescing.
Alternately, the CPU can perform the Level-n read directly, avoiding the use of the monitor hardware. In this case the bus semantics are the same. OS software in some cases may choose to enter C-states through this legacy path. For a multi-threaded or multi-core system, OS software would need to know that all other threads and cores were in a compatible C-state before issuing the Level read. For single-threaded single-core systems the legacy Level read can be issued unconditionally.
While some CPUs support power saving modes as described above, some lower cost or lower performance CPUs, which may otherwise be well suited to certain mobile applications, may omit hardware support for deeper power saving modes and, therefore, do not allow core logic to take advantage of its built-in hardware for power savings to achieve system-level power savings.